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I nteroperability Testing 


Prcxiessesfor verifying and troubleshcwting communication between your 
local H P node and another node on the network. 
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Interoperability Testing 

Testing FTAM Interoperability 


Testing FTAM Interoperability 

Usethefollowing prcxedurestotest FTAM Interoperability. 

FTAM Interoperability Testing 

1. Log on as root. 

2. Perform the pre-test checklist. 

3. Create a result file. 

4. Perform FTAM tests. 

5. If osidiag cannot find a default local application title, perform 
"Specifying Application Titles." 

6. I nterpret errors. 
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Interoperability Testing 

FTAM Pre-Test Checklist 


FTAM Pre-Test Checklist 

Check the following before attempting to run the FTAM tests. 

Figure 1-1 FTAM Pre-Test Checklist 
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Interoperability Testing 

FTAM Interoperability Testing 


FTAM Interoperability Testing 

This prcxedure invokes FTAM through osidiag to provide as much 
information as possible about errors that might occur. 

FTAM Connectivity Test 

The steps below describe how to test FTAM connectivity between the 
local and remote node. 

1. From root, type osidiag and select "FTAM TESTS." 

2. Create a result file. 

3. Select "Connect" from the FTAM menu. 

4. Enter I nitiator Identification (your login information for the remote 
node). 

• Change ID field from local login name to remote unless login on 
remote is the same. 

• Enter initiator password associated with remote login. 

5. Press Done. 

6. E nter Presentation Address for remote node. 

7. Gotothe'TTAM File Transfer Test" on page 15. 
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Interoperability Testing 

FTAM Interoperability Testing 


FTAM File Transfer Test 

After a successful FTAM connect test. Follow the steps below to do an 
FTAM file transfer. 

1. From the FTAM menu, create a new result file. 

2. Select "Low Level Transfer." 

3. The initiator ID parameters are displayed. 

a. Leave first ID set to local login. 

b. Set first password to your local password. 

c. Leave second set unchanged. 

d. Press Done. 

4. Leave source Presentation address unchanged. Press Done. 

5. Leave destination address unchanged. Press Done. 

6. If your system has a "message of the day" configured, leave the source 
and destination file names unchanged. If your system does not have a 
"message of the day" configured, overwritethe source filename with a 
valid name. 

7. Check 'TEST STATUS" near the end of the report. 

If the status is "PASSED," FTAM verification is complete. 

If the status is "FAILED," see "Interpreting FTAM Errors" on page 
16, make your corrections, then re-run this test. 
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Interoperability Testing 

Interpreting FTAM Errors 


Interpreting FTAM Errors 

Table 1-1 may help you to find what caused your FTAM test to fail. 

1. Check the field labeled "Diagnostic". 

If this field is present, look for a text string labeled "further details" 
for the cause. 

2. Look at the line after "FAI LED". The operation that failed is listed. 

Table 1-1 FTAM Call Errors 


FTAM Call 

Reason 

Corrective Action 

ft_aeactivation() 

FTAM not correctly 
installed. 

Run swverify on the FTAM 
fileset to verify that all 
components are installed. 

OTS stack not up. 

Run the Status operation 
under Session or Transport to 
verify. 

ft_connect() 

1 ncorrect address 
specified. 

Recheck the value of the 
Presentation address specified 
and the value configured for 
the remote. 

1 ncorrect User 1D. 

Check user name and 
password, usually corresponds 
to the remote. 

Remote stack not up. 

Recheck stack. 

Responder not running. 

Repeat the verification 
described in the pre-test 
section. 

Lower Layer Problem. 

Go back to the step you were 
on and continue. 

ft_select{) 

1 ncorrect source file 
name. 

Check the source file name 
and correct. 
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Interoperability Testing 

Interpreting FTAM Errors 


FTAM Call 

Reason 

Corrective Action 

ft_create () 

Permission problem or 
incorrect directories were 
specified in the path for 
the destination file name. 

Check the permissions and 
the directories specified. 

ft_sdata() 

Transfer filetoo large. 
(Error code 101 Buffer 
too large error). 

Rerun the test with a smaller 
file or use the High Level 

Transfer test. 

ft_xxx() 

U ncommon poi nts of 
error; or, if an abort 
indication is received, the 
remote went down for 

some reason. 

Check the remote stack and 
FTAM responder if an abort 
indication is indicated. 
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Interoperability Testing 

Testing APRI Interoperability 


TestingAPRI Interoperability 

The steps below describe how to test the ACSE/Presentation and ROSE 
(APRI) layer connectivity between the local and remote node. Usethis 
only if you are develop! ng APRI programs and wish to verify connectivity 
at this layer. 

1. Log on as root. 

2. Perform the pre-test checklist. 

3. Perform APRI test - Client Mode. 

4. Perform APRI test - Server Mode (optional). 

5. If osidiag cannot find a default local application title, perform 
"Specifying Application Titles." 

6. I nterpret errors. 
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Interoperability Testing 

APRI Pretest Checklist 


APRI Pretest Checklist 

Check the following before attempting the APRI I nteroperability tests. 

Figure 1-2 APRI Pre-Test Checklist 
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Interoperability Testing 

Running APRI Tests (Client Mode) 


Running APRI Tests (Client Mode) 

The following steps verify APRI connectivity and interoperability with a 
remote node. 

If the remote is not capable of receiving connections, or you want to test 
the remote's ability to establish connections, follow the instructions in 
"Running APRI Tests (Server Mode)" on page 21. 

1. From root, type /opt/ots/bin/osidiag and select 
"ACSE/Presentation or ROSE Tests." 

2. Create a result file. 

3. Make sure a server application is running on the remote. Then, select 
"Connect"from theTest Case menu. 

4. E nter Presentation Address when prompted. 


NOTE osidiag will display the local address by default. The default P, S, andT 

selectors are given in ASCII surrounded by double quotes. Ifthe address 
you must use is specified in hexadecimal rather than ASCI I, then omit 
the double quotes (for example, 22003176). 


5. Enter Proposed Contexts when prompted. 

6. Enter Application Context when prompted. 

7. For ROSE only: E nter the context identifiers when prompted. 

8. Check the 'TEST STATUS" near the end of the report. 

Ifthe status is "PASSED," you have successfully communicated with 
the remote node and are finished with this section. 

lfthestatusis"FAILED,"see"lnterpretingAPRI Errors"on page 22, 
and find problem. 

If you find the error, rerun this test. 

If you cannot find the error, enable tracing. See 'Tracing and Logging 
through /opt/ots/bin/osidiag" on page 62 for more information. 

9. Go to the APRI Tests (Server Mode). (Optional) 
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Interoperability Testing 

Running APRI Tests (Server Mode) 


Running APRI Tests (Server Mode) 

If the remote is not capable of receiving connections, or you want to test 
the remote's ability to establish connections, follow these instructions. 

1. From root, type /opt/ots/bin/osidiag -w 300 (the -w 300 
allows 300 seconds to get the client ready once the server is started), 
and select "ACSE/Presentation or ROSE Tests." 

2. Create a result file. 

3. Select "Server..." from the Test Case menu. 

4. For ROSE only: Enter the Presentation context identifiers to be used 
as ROSE contexts. 

5. For ROSE only: Leave the autorespond to ROSE default set to "Y". 

6. Generate the connection from the client side via the remote 
application. Follow steps in the APRI Tests (Client Mode) if an FI P 
system. 

7. Check the 'TEST STATUS" near the end of the report. 

If the status is "PASSED," you have successfully communicated with 
the remote node and are finished with this section. 

lfthestatusis"FAILED,"see"lnterpretingAPRI Errors"on page 22, 
and find the problem. 

If you find the error, rerun the server test and rerun the client test on 
the remote to connect to this server. 

If you cannot find the error, enable tracing on the local node. See 
'Tracing and Logging through /opt/ots/bin/osidiag" on page 62 for 
more information. 
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Interoperability Testing 

Interpreting APRI Errors 


Interpreting APR I Errors 

Table 1-2 describes possible errors and corrective actions if an error 
occurs during a call to APRI. 

Table 1-2 APRI Call Errors 


APRI Call 

Reason 

Corrective Action 

ap_open () 

I ncorrect installation or OTS 
stack is not up. 

Run otsstat to see if 
OTS stack is up. Run 
ots start to start OTS 
stack. 

ap_set_env() 

I ncorrect address specified, 
(parameter ap_my_psap) 

Recheck the value of 
ap_my_psap. 

ap_poll() 

Timeout (osidiag defaults to 
30 seconds for indication or 
confirmation). 

I ncrease ti me if needed. 

Unanticipated primitive 
(osidiag received an 
indication it did not expect.) 

Check osidiag display 
immediately after the 
call to ap_poll () . 

ap_rcv(A_PABORT_IND) 

I ncorrect remote address. 

Recheck remote 
address; check that local 
NSAP Ison same subnet 
as the destination 
system. 

ap_rcv(A_ABORT_IND) 

The application on top of the 
Presentation layer detected 
some problem. An abort may 
also be sent by the H P 
provider if the specified 
address is valid, but no 
process is currently accepting 
connections. 

E xami ne the output of 
the remote application 
for further information 
as to why the abort was 
sent. 
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Interoperability Testing 

Interpreting APRI Errors 


APRI Call 

Reason 

Corrective Action 

ap_rcv(A_ASSOC_CNF) 

Your connect request arrived 
at the remote, but the remote 
did not I ike one of your 
proposed values or it is not 
available to service 
connections. The confirmation 
carries three pieces of 
information: the result, the 
source (if rejected), and a 
diagnostic code. 

Examine the diagnostic 
code for the course of 
action. 

ro_bind() 

The values you specified are 
not compatible with those 
negotiated. 

Verify that the val ues 
for ap_p_ctx_list and 
rose_pci_list are 
consistent. 
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Testing Session interoperabiiity 


Testing Session Interoperability 

The steps below describe how to test the session layer connectivity 
between the local and remote node. Usethisonly if you are developing 
session programs and wish to verify connectivity at this layer. 

1. Log on as root. 

2. Perform the pre-test checklist. 

3. Perform Session tests - Client Mode. 

4. Perform Session tests - Server Mode (optional). 

5. If osidiag cannot find a default local application title, perform 
"Specifying Application Titles." 

6. I nterpret errors. 
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Interoperability Testing 

Session Pre-Test Checklist 


Session Pre-Test Checklist 

Figure 1-3 Session Pre-Test Checklist 
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Running Session Tests (Ciient Mode) 


Running Session Tests (Client Mode) 

Normally you use this list of steps to verify connectivity and 
interoperability with a remote node. If the remote is not capable of 
receiving connections, or you wish to test the remote's ability to establish 
connections, follow the instructions in "Running APRI Tests (Server 
Mode)"on page 21. 

1. From root, type /opt/ots/bin/osidiag and select "Session Tests." 

2. Create a result file. 

3. Make sure a server application is running on the remote, then: Select 
"Connect"from theTest Case menu. 

4. Enter the destination Session Address when prompted. NOTE: 
osidiag will display the local address by default. 

5. Check the 'TEST STATUS" near the end of the report. 

If the status is "PASSED," you have successfully communicated with 
the remote node and are finished with this section. 

If the status is "FAI LED," see "I nterpreting Session Errors" on page 
28 to find the problem. 

If you find the error, rerun this test. 

If you cannot find the error, enable tracing. See'Tracing and Logging 
through/opt/ots/bin/osidiag" on page 62. 

6. Go to "Running APRI Tests (Server Mode)" on page 21 (Optional). 
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Interoperability Testing 

Running Session Tests (Server Mode) 


Running Session Tests (Server Mode) 

If the remote is not capable of receiving connections, or you wish to test 
the remote's ability to establish connections, follow these instructions. 

1. From root, type /opt/ots/bin/osidiag -w 300 (the -w 300 
allows 300 seconds to get the client ready once the server is started), 
and select "Session Tests". 

2. Create a result file. 

3. Select "Server..." from the Test Case menu. 

4. Generate the connection from the client side via the remote 
application. Follow steps in "Running APRI Tests (Client Mode)" on 
page 20, if an FI P system. 

5. Check the 'TEST STATUS" near the end of the report. If the status is 
"PASSED," you have successfully communicated with the remote 
node and are finished with this section. 

If thestaus is "FAI LED," see "I nterpreting Session Errors" on page 
28. 

If you find the error, rerun the server test, then rerun the client test 
on remote to connect to this server. 

If you cannot find the error, enable tracing on the local node. See 
'Tracing and Logging through /opt/ots/bin/osidiag" on page 62. 
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Interpreting Session Errors 


Interpreting Session Errors 

Table 1-3 describes possible errors and corrective actions. The list is 
sorted by the name of the function producing the error. The names are 
displayed by osidiag on the line immediately after the test status. 

Table 1-3 Session Call Errors 


Session Call 

Reason 

Corrective Action 

osi_init ( ) 

Usually lack of available 
swap space. 

Add swap space as necessary. 

osi_rgr_rq() 
osi_rgr_cf() 

Possibly stack is not up. 
Another application is 
already listening on this 
address or has requested 
excl usi ve access to th i s 
address. 

Check tosee if stack is up. See 
if another applications is 
using this address or has 
exclusive access. 

osi_get_event() 

Two common errors: 

1. Time out - osidiag only 
waits 30 seconds by default. 

M ay i ndi cate that the remote 
is not sending any response 
to your request. 

2. Unanticipated primitive- 
osidiag received an 
indication that it did not 
expect. 

Verify that the remote is 
indeed performing its end of 
the dialog. If the timeout is 
too short, it may be changed 
under the utilities menu. The 
name of the i ndi cat! on wi 11 be 
displayed immediately after 
the call to 

osi_get_event() . 

ses_pabort_id() 

U sed to decode an i ncomi ng 
provider abort indication. 

For more information see 
"Protocol Reason Codes"on 
page 44. The reason code 
appears i n the middle of the 
osidiag output. 

Check the reason code and 
correct accordingly. 
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Interpreting Session Errors 


Session Call 

Reason 

Corrective Action 

ses_uabort_id() 

U sed to decode i ncomi ng 
abort indication. Indicates 
the application on top of the 
Session layer detected some 
problem. 

E xami ne the output of the 
remote application for 
further information as to why 
the abort was sent. 

ses_connect_rf() 

Called to decode a refusal to 
connection request. I ndicates 
that your connect request 
arrived at the remote, but 
remote did not like one of 
your proposed values or it is 
not available to service 
connections. The refuse code 
is displayed in the middle of 
theosidiag output. 

Check the remote to see if it is 
available to service 
connections. Also check your 
proposed values. For more 
information on disconnect 
codes and suggested actions, 
See "I nterpreti ng Transport 

E rrors" on page 33. 
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Testing Transport Interoperability 


Testing Transport Interoperability 

The steps below describe how to test Transport layer connectivity 
between the local and remote node. 

1. Log on as root. 

2. Perform the pre-test checklist. 

3. Perform Transport tests. 

4. If osidiag reports "FAILE D", see "I nterpreting Transport Errors" on 
page 33. 
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Transport Pre-Test Checklist 


Transport Pre-Test Checklist 

Figure 1-4 Transport Pre-Test Checklist 


▼ 


Is the remote stack up? No 

Yes 

▼ 


Do the Transport 
Interoperability Tests 
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Running Transport Tests 


Runni ng T ransport Tests 

1. From root, type /opt/ots/bin/osidiag and select 'Transport 
Tests." 

2. Create a result file. 

3. Make sure a server application is running on the remote, then select 
"Connect" from the Transport Tests menu. 

4. Enter the destination T ransport Selector and Network Address when 
prompted. NOTE: osidiag will display the local address by default. 
The default P, S, andT selectors are given in ASCII surrounded by 
doublequotes. If the address you must use is specified in hexadecimal 
rather than ASCI I, then omit the double quotes (for example, 
22003176). If you aretesting RFC 1006 interoperability, enter the 
RFC1006 NSAP for the remote system. 

5. Check the'TEST STATUS" near the end of the report. 

If the status is "PASSED," you have successfully communicated with 
the remote node and are finished with this section. 

If the status is "FAI LED," see "I nterpreting Transport Errors" on 
page 33 to find the problem. 

If you find the error, rerun this test. 

If you cannot find the error, enable tracing. See'Tracing and Logging 
through/opt/ots/bin/osidiag" on page 62. 
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Interpreting Transport Errors 


I nterpreti ng Transport E rrors 

The following are possible situations you may currently find yourself in. 

Transport problem corrected. 

If you have made a change that corrected your Transport problem, then 
return to the Service Layer test that originally failed and try again. 

Configuration or other change required. 

If the corrective action in the foil owing sections require you to change a 
configuration parameter or make some other change, then do so and 
rerun the Transport test. 

Problem persists. 

If you have been unsuccessful in correcting the problem, gather the 
information you have collected to provide to your HP support 
representative. 

Table 1-4 Transport Call Errors 


Error 

Reason 

Action 

t_open() 

The stack is most likely 
not up. 

Run status operation under 

Transport menu. 

t_bind() 

Failed to associate an 
address with thetransport 
endpoint. Likely a 
parameter error. Link 
supporting this address 
went down. 

Verify that the parameter 
tp my tsap is set to "diagt" or 
"diagt.N SAP"whereNSAP is 
valid local address. Run status 
operation under Transport menu. 

t_rcvdis() 

Called to decode a 
disconnect indication. 

Check online error messages. 

t_look() 

Remote stack does not 
respond for default time. 

Check to see if one node is 
configured as NULL internet and 
other is not. Check for incorrect 
remote network address. 
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Testing LAN (802.3or FDDI) 
Interoperability 

The steps below describe how to test connectivity at the Link level 
(either 802.3 or FDDI LAN) between the local and remote node. 

1. Log on as root. 

2. Perform the pre-test checklist. 

3. Perform LAN test. 

4. If osidiag reports "FAI LED," see "I nterpreting LAN Errors" on 
page 37. 


34 


Chapter 1 




Interoperability Testing 

LAN Pre-Test Checklist 


LAN Pre-Test Checklist 

Figure 1-5 LAN Pre-Test Checklist 
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Running LAN Tests 


Running LAN Tests 

1. From root, type /opt/ots/bin/osidiag and select "LAN Tests." 

2. Create a result file. 

3. Select'Test Frames." 

4. Enter the interface name to issue the test from (lanO, I an 1, etc). The 
default from the ots_subnets file can be used unless you have 
multiple I/O Cards. 

5. Enter the value previously retrieved for the remote MAC address in 
hexadecimal (always 6 bytes -12 hex digits). Do not include the 
leading "Ox" if present. 

6. I f the test status field says "PASSE D," proceed to 'Testi ng Transport 
Interoperability"on page 30. 

I f the test status field says "FAl L E D," see "I nterpreti ng L AN E rrors" 
on page 37. 
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Interpreting LAN Errors 


Interpreting LAN Errors 

The following are possible situations you may currently find yourself in. 

LAN problem corrected. 

If you have made a change that corrected your LAN problem, then 
proceed to the OTS layer tests. 

Configuration change required. 

If the corrective action in the foil owing sections require you to change a 
configuration parameter, then do so and rerun the LAN test. 

Problem persists. 

If you have been unsuccessful in correcting the problem, gather the 
information you have collected to provide to your HP support 
representative. 

Table 1-5 LAN Errors 


Error 

Reason 

Action 

LAN I nterface Name 

The "interface name" is 
extracted from the OTS 
subnet configuration. If 
the device is not open, it 
may have the wrong 
value configured (or no 
value). 

Check the parameter 
lanX_if_name from the 
top of the osidiag output 
and verify that this 
interface exists using the 
lanscan command. 

open () 

Opens the DLPI stream 
device. Device file 
/dev/dipi may not exist. 

Create device file using 
mkdev(lM) command. 

getmsg (DL_BIND_ACK) 

Used to set up various 
options for LAN access. 

Possi ble errors: 

^Setting SSAP. Sets Link 
Service Access Point. Will 
fail if it is currently in use 
by another osidiag 
process or by OTS. 

If OTS is running, make 
sure OTS will not be 
started when the system 
comes up and reboot the 
system to perform this 
command. 
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Error 

Reason 

Action 

getmsg (DL_TEST_CON) 
getmsg (DL_UNITDATA_ACK) 

Receives information 
from the remote either on 
Receive or Test F rame 
operation. Usually means 
time out. 

Check MAC address 
specified, and cabling 
between the two systems. 

I f neither is true, check to 
see if remote supports 

IEEE 802.3TEST frames. 

putmsg (DL_TEST_REQ) 

The local system is not 
configured to use IEEE 
packets. 

Check and correct as 
necessary using the 
lanconfig(lM) command. 

putmsg (DL_UNITDATA_REQ) 

Data exceeds maximum 
MTU size for LAN. 

Use "status" in LAN Test 
menu to determine MTU 
size. 
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Testi ng X.251 nteroperabi I ity 

The steps below describe how to test connectivity at the Network Layer 
for nodes connected via X.25. 

1. Log on as root. 

2. Perform the pre-test checklist. 

3. Perform X.25 test. 

4. If osidiag reports "FAILE D," see "I nterpreting X.25 E rrors" on page 
42. 
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X.25 Pre-Test Checklist 

Figure 1-6 X.25 Pre-Test Checklist 
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Running X.25 Tests 

1. From root, type osidiag and select "WAN X.25Tests." 

2. Create a result file. 

3. Select "Connect." 

4. Enter the value for the remote X. 121 address. This value is both the 
address for the remote card and any subaddress concatenated into a 
single decimal number. 

5. Leave the X.25 I nterface name unchanged. 

6. For CONS change the protocol ID to the value 03010100. For CL NS, 
change the protocol ID to 81. Press Done. 

7. I f the test status field says "PASSE D," proceed to 'Testi ng Transport 
Interoperability"on page 30. 

I f the test status field says "FAIL E D," see "I nterpreti ng X.25 E rrors" 
on page 42. 
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I nter preti ng X.25 E r rors 

The following are possible situations you may currently find yourself in. 

X.25 problem corrected. 

If you have made a change that corrected your X.25 problem, then 
proceed to the Transport layer tests. 

Configuration change required. 

If the corrective action in the foil owing sections require you to change a 
configuration parameter, then do so and rerun the X.25 test. 

Problem persists. 

If you have been unsuccessful in correcting the problem, gather the 
information you have collected to provide to your HP support 
representative. 

Table 1-6 X.25 E rrors 


Error 

Reason 

Action 

socket () 

X.25 is not installed on your 
system. 

1 nstall X.25. 

bind () 

If OTS is running, osidiag is 
not able to bind to the same 
X. 121 address the stack is 
using. 

1 f supported by a switch, try bi ndi ng to a 
different subaddress or the NULL 
subaddress. 

connect () 

1 nvalid programmatic 
access name. 

Use default or leave blank. Can also verify 
the val ue by issuing the "Status..." 
operation through the X.25 Tests. 


42 


Chapter 1 





Interoperability Testing 

Interpreting X.25 Errors 


Error 

Reason 

Action 

recv(*00B*) 

Errors related to the receipt 
of an unexpected CLEAR or 
RESET packet. 

Some common diagnostics: 

(0) No additional information - may 
indicate that the request was delivered to 
the remote, but it was rejected by the OSI 
stack. Check Protocol ID. 

(67) Call setup problem; I nvalid called 
address. Check addresses of the remote 
and correct. 

(231) Connection Rejection - NSAP 
Unreachable. Check the Protocol 1D and 
subaddress. 
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Reason and Refuse Codes 

Protocol Reason Codes 

The following are reason codes that may be logged or returned to your 
program. 

Session Provider Abort Reason Code 

The value passed back to Session programs by the ses_pabort_id () 
routine. 

Transport Disconnect Reason Code 

The value passed back to XTI program by the t_rcvdis o routine. 

ASCE/Presentation DCNX KO Log Message 

The value shown in the second low order byte of the Cause field (f3 in 
Cause =0x0001f3ff). 

Session S_REJ ECT Log Message 

The value shown in the second low order byte of the Cause field (f3 in 
Cause =0x0001f3ff). 

Transport T REJ ECT Log Message 

The value shown in the second low order byte of the Cause field (f3 in 
Cause =0x0001f3ff). 

Network N REJ ECT Log Message 

The value shown in the second low order byte of the Org/Reas field (the 
"08"inOrg/Reas=0108). 

Table 1-7 shows the reason codevalue, its meaning, and possible 
corrective actions. 


Table 1-7 Reason and Refuse Codes 


Code 

Meaning 

Action 

(0) 

Normal disconnect Specified address may be 
correct, but there is no process listening for a 
connection. 

Verify that OSI services are 
up in the remote. Verify that 
theT-selector is specified. 
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Code 

Meaning 

Action 

(0x01) 

Provider N-Disconnect (Transient) 

Previously active network connection was 
abruptly disconnected. Congestion at TSAP 
Some vendor's equipment may indicate that 
the application above transport is not 
capable of receiving any more connections. 

The X.25 card or the switch 
may have gone down. 

Check the remote for any 
further logged information. 

(0x02) 

Provider N-Disconnect (Permanent) 

Previously active network connection was 
abruptly disconnected. Transport User Not 
Attached to TSAP 1 ndicates that the address 
specified is valid, but that no process capable 
of receiving connections is active. 

The X.25 card or the switch 
may have gone down. 

Verify that server is active on 
remote. 

(0x03) 

Provider N_Reject (Transient) Network 
connection could not be established. 

Address Unknown 

Address specified was incorrect. 

Check the NSAP and T- 
selector. 

(0x04) 

Provider N_Reject (Permanent) Request to 
establish a network connection was rejected. 

Check for facility rejection, 
non-use of fast select, reverse 
charge failure, switch or PDN 
out of order. 

(0x05) 

Provider N_Reject (QOS unavail/Transient) 

QOS negotiation failed for this connection. 


(0x06) 

Provider N_Reject (QOS unavail/ 

Permanent) 

QOS negotiation failed for this connection. 


(0x07) 

N-Reject (NSAP unreachable/Transient) 

Network connection could not be established 
because there were not enough VCs or 
resources available. 

Usex25stat to examine the 
state of the network card. 

Check log file for QTS 
messages. 
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Code 

Meaning 

Action 

(0x08) 

N-Reject (NSAP unreachable/Permanent) 

Network connection could not be established 
because the X.121 address was I ncorrect. 

Use osiadmin or otsshowes 

to examine the configured 

X.121 address for this N SAP. 
Verify if remote is up and 
listening on the configured 
address. 

(0x09) 

N-Reset from NS Provider (No Reason) 

Network connection was reset. 

No recognized diagnostic is 
provided. 

(OxOa) 

N-Reset from NS Provider (Congestion) 

Network connection was reset. 

X.25 diagnostic indicates 
provider was a problem. 

(OxOb) 

N_Reject (Address Unknown) 

No destination or route entry exists for the 
given NSAP. Network connection cannot be 
established. 

Use osiadmin or otsaddes 

to configure the desti nati on 
system. 

(0x12) 

Disconnect for NS User Remote Transport 
layer encountered a failure and abruptly 
released the network connection. 


(0x14) 

User N_Reject (Transient) 

The remote Transport layer refused this 
network connection request. 


(0x15) 

User N_Reject (Permanent) The remote 

Transport layer refused this network 
connection request. 


(0x16) 

User N_Reject (QOS unavail/Transient) 

QOS negotiation failure 


(0x17) 

User N_Reject (QOS unavail/Permanent) 

QOS negotiation failure 


(0x18) 

N_Reject ((Unrecognized NS-user- data) 
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Code 

Meaning 

Action 

(Oxla) 

Network Reset from NS User (Resynch) 

Network connection was reset. 

X.25 diagnostic indicates 
resynchronization was 
requested. 

(0x20) 

Undefined reason, unknown origin Indicates 
some X.25 problem. 

Check for down card on local 
or remote, switch, or facilities 
negotiation. 

(0x21) 

1 nvalid Parameter (OTS Kernel) 

An encoded parameter is invalid. 

Check for N SAPs that are too 
large or missing. 

(0x22) 

External Protocol Error (OTS Kernel) 

Fai 1 ure decodi ng fad 1 ity I nformation. 

An error should be logged 
describing the protocol error. 

(0x23) 

1 nvalid 1 nternal State (OTS Kernel) 

A network primitive was received or is to be 
sent in an unexpected state. 

An error should be logged 
describing the protocol error. 

(0x24) 

Facility or Data Field Overflow (OTS Kernel) 

Processing of the facility fields indicated 
failure 

An error should be logged 
describing the protocol error. 

(0x41) 

X.25 Facility Requested not Allowed 

The configured X.25 facilities do not match 
those of the provider. 

Determi ne the fad 1 ities 
available and reconfigure 

OTS and X.25 to use the 
appropriate set. 

(0x42) 

Could not Access X.121 Address of Remote 

The X. 121 address mapped to the NSAP you 
specified is incorrect or the remote system is 
down. 

Reset the remote system or 
reconfigure the OTS routing 
table appropriately. 

(0x81) 

Remote Transport Entity Congestion at 
Connect Time 

1 ndicates that no problems were detected 
with the Transport layer, but user of service 
may have sent an abort or other higher level 
error. 
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Code 

Meaning 

Action 

(0x82) 

Connection Negotiation Failed 

M ay be a problem with the classes specified 
(transport over CONS error). 

Check to see if remote only 
uses cl ass 0.1 f so you mi ght 
reconfigure the local stack to 
force class 0. 

(0x83) 

Duplicate Source Reference for Same NSAP 

This is a protocol error. 

The caller must generate a 
unique reference number for 
each connection it forms. 

(0x84) 

Mismatched References 

Either a protocol error, or may indicate that 
the remote stack was taken down and 
brought back up while existing connections 
remained. 

Check the state of the remote 
stack. 

(0x85) 

Protocol Error 

Check any logged 
information on the remote 
side. Also verify the stack was 
not being brought up at the 
time. 

(0x88) 

Connection Request Refused on this Network 
Connection 

The level of multiplexing configured for the 
local node may not be compatible with that 
on the remote. 

On HP systems, examine the 

Transport over CON S 
parameters 

tpcons_max_con_mux_in 

and 

tpcons_max_con_mux_out 

and change if max out exceeds 
max in. 

(0x8A) 

Header or Parameter Length I nvalid 

I ndicates a protocol error. 

Check log information on 
remote. 

(0xE4) 

X.25 Network Error or Network Down 

Run x25stat to determine 
the status of the X.25 link. 

M ay need to restart X.25 or 
reset other X.25 hardware. 
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Code 

Meaning 

Action 

(0xE7) 

Problem Accessing X.25 Subaddress of 

Remote 

Subaddress portion of X.121 from the OTS 
routing table is incorrect or the remote is not 
up. 

Correct the routing table or 
bring up the remote. 

(0xE8) 

NSAP not Configured 

Network address portion of the address 
specified is not configured in the routing 
table. (Not usually LAN) 

Configure remote X.25 usi ng 

osiadmin. 

(OxFO) 

Protocol Error Detected by Remote's 

T ransport 

Remote encountered an error decoding one o 
the Transport PDUssent by us. 

Generate a trace and contact 
your FI P support 
representative. 

(OxFl) 

Protocol Error Detected by Remote's Session 

Remote encountered an error decodi ng one of 
the Session PDUssent by us. 

Generate a trace and contact 
your FI P support 
representative. 

(0xF3) 

I nvalid Address or Permanent Transport 

Error 

Usually returned when an invalidT- selector 
or Network Address is given. Could also get 
when remote stack is not running or the 
remote's X.121 address is not associated with 
its NSAP. 

Useosiconf to associate 

X.121 address with NSAP. 

(OxF4) 

1 nvalid Address or Permanent Session Error 

Check address specified, and 
state of remote stack to 
ensure it is running. 

(0xF6) 

X.25 Unavailableor Transient Transport 

Error 

Verify that X.25 is up by 
running x25stat operation. 

(0xF7) 

Transient Session Error 

Verify status of remote stack. 
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Code 

Meaning 

Action 

(0xF9) 

Protcxiol Error Detected by Local Transport 

Error encountered decoding a PDU sent by 
the remote Transport entity. 

Generate a trace and contact 
your FI P support 
representative. 

(OxFA) 

Protocol Error Detected by Local Session 

Error encountered decoding a PDU sent by 
the remote Transport entity. 

Generate a trace and contact 
your FI P support 
representative. 

(OxFC) 

1 nsufficient Resources for Local Transport 

Stack experiencing resource problems. 

Examine other OTS 
processes running. Contact 

FIP support representative if 
condition persists. 

(OxFD) 

Insufficient Resources for Local Session 

Stack experiencing resource problems. 

Examine other OTS 
processes running. Contact 

FIP support representative if 
condition persists. 

(OxFE) 

1 nsufficient Resources for Local 
ACSE/Presentation 

Stack experiencing resource problems. 

Examine other OTS 
processes running. Are you 
near the448connection limit? 
Contact FIP support 
representative if condition 
persists. 

(OxFF) 

Local User Error 

Usually caused by overriding parameter 
default values, Could result from trying to 
run an operation in the wrong state. 

Check parameters values you 
changed. 

(01-EF 

X.25 

FO-FF 

T ransport 

Code Unknown 

An unrecognized error code was received. 

Examine documentation of 
other vendor for disconnect 
reason codes. If X.25 range, 
run an X.25 connection test, 
the diagnostic information 
may be helpful. 
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Table 1-8 


Session Refuse Codes 

Table 1-8 describes the meanings defined by I SO 8327 for the reason 
codes carried on a negative Session connect confirmation. These values 
are logged after s_C0NNECT_Resp (Negative) message, and on return 
from the ses_connect_rf () library call. 

Session Refuse Codes 


Code 

Meaning 

0 

Reason not specified. 

1 

Rejection by called Session service user due to 
temporary congestion. 

2 

Rejection by called Session service user. The 
followi ng octets may be used for up to 512 octets of 
user data. 

81 

SSAP identifier unknown. 

82 

Session service user not attached to SSAP. 

83 

SBM congestion at connect time. 

84 

Proposed protocol versions not supported. 
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To Create A Result File 

Use the foil owing steps to create a result file. Itcan be reached from 
several osiadmin menus. 

1. Select "Utilities"from a services menu. 

2. Select "Open Result File". 

3. Enter the name of your file (for example, /tmp/ftam. res). 

4. Press Done. 

5. Press the space bar when a message appears showing the file was 
opened. 

I f the message shows an error, check the name you specified. 

6. Press Previous Menu. 
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I nformation and prcxiedures for identifying and troubleshooting 
problems that you may encounter using Hewlett-Packard's OSI products. 
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Basic Steps 


NOTE If the problem you encounter occurs only when communicating with 

another system, seeChapter 1, "InteroperabilityTesting,"on page 11. 


1. I nterpret the initial error. Tofind more information about thespecific 
error, see "I nterpreting Errors"on page 55. 

2. Determi ne the status of components. M ake sure al I the OSI product 
components are up and running. See "Checking System Status" on 
page 56. 

3. Verify operation. If all components report that they are up and the 
problem persists, verify the ability of the link (X.25, 802.3 or FDDI), 
the stack, and the specific service you are using to communicate. See 
"Running Verification Tests" on page 58. 

4. Gather more information. If the information from the basic 
verification test was insufficient to diagnose the problem, then you 
can get additional information through Hewlett-Packard's tracing 
and logging facilities. See "CollectingTroubleshooting Data" on page 
61. 

5. Validate configuration. If you have not already done so, run 
osiconfchk to validate the Configuration. For a description of this 
tool, seeChapter 3, "Using OSI and OTS Tools,"on page 71. Also 
check the possible problems listed in "Common Configuration 
Mistakes"on page 65. 

6. Validate installation. If the system behavior is still not correct, check 
that your software installation has not been corrupted. The tool 
swverifyllM) performs this task. 

7. Submit information to HP. If you were not successful in diagnosing 
and correcting the problem, contact your H P support representative. 
See "Submitting Problem I nformation to HP"on page 70. 
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Interpreting Errors 

This section describes where you should look to find more information 
about an error you encountered. Table 2-1 gives the places where you 
may encounter errors and how to interpret them. 


Table 2-1 Interpreting Errors 


Where 

Action 

osidiag 

You will find a description of how to interpret errors at the end of 
each section in Chapter 1, "1 nteroperability Testing,"on page 11. 

netti log files 

Many errors contain detailed text describing the problem. Some 
common logged errors are described at the end of this chapter. 

User applications 

Errors received in applications you write are passed back through 
return codes. You may want to use the API tracing facility for the 
interface. The netti log file many also contain information. You 
could also increase the logging level and reproducethe problem. See 
'Tracing and Logging through /opt/ots/bin/osidiag" on page 

62. 

FTAM 

1 nteractive 
Commands 

These errors are described in the H P FTAM/ 9000 User's Guide and 
the FI P FTAM/9000 Reference Manual. 

X.400 Commands 

Refer to the Managing X.400—Administrator's Guide 

OSI/OTS 

Administrative 

Commands 

These errors are produced from commands like otsstart and 
osiconfchk. Descriptions of these errors can be found online. Also 
look in the log files in /var/opt/ots. 

System Panics 

Panics occur when an irrecoverable error is detected bytheFIP-UX 
operati ng system. At reboot after a panic, a copy of the state of the 
system will be saved by savecore. See 

/etc/rc.config.d/savecore. You may need to create a special 
directory for savecore to actually savethe image to disk. 

1 nterpreting panics is done by your FI P support representative or the 
factory. 
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Checking System Status 

There are several tcxolsthat allow you to check if the links, stack, and 
services are up and running. Perform the following steps to verify that 
your local system is up. 

Status Check 1 

1. Run otsstat to verify the status of OTS and its attachment to the 
underlying links. 

2. If status says "RUNNING," goto Status Check 2. 

3. If status says "NOT RUNNI NG," start the stack using otsstart or 

osiadmin. 

If Still "NOT RUNNI NG," run osiconfchk. This indicates a 
configuration problem. 

Status Check 2 

1. If one or more LAN cards are configured, run lanscan to show status 
of al I LAN cards on the system. 

2. If net interface state shows "DOWN,"the card is disabled. Restart the 
card by running osiadmin or ifconfig. If the card is still down 
after starting it, check for hardware or cabling problems. 

3. If OTS still shows link is "DOWN" while lanscan shows it as up, 
verify that the configured interface name shown by otsstat matches 
that shown by lanscan. 

Status Check 3 

1. If one or more X.25 cards, run x 25 stat, against each card's devicefile 
name. 

2. If the message says "not currently active," start the card using 

osiadmin or x25init. 

3. If the message says "Level 2 is DOWN," there is a communication 
problem between the card and the switch. Check the cabling and the 
configuration of the device the X.25 card is connected to. 
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Status Check 4 

1. If you areusingtheFTAM Service, run osistat to verify that the 
shared memory segment is present and to display the number of 
currently active FTAM applications. See Chapter 3, "Using OSI and 
OTS Tools," on page 71, for more information on osistat. 

2. If you are using FTAM, then the count of "Active FTAM responder 
service providers" should be one or more. If not, then run osiadmin 
or osistart to Start FTAM. 

3. If osistat indicates that it is"Unabletoaccesstheshared-memory 
segment" formatting, you may need to regenerate the kernel to 
increasethe available amount of shared memory or semaphores. 

Status Check 5 

1. If you are running X.400, then type /opt/x400/bin/x4stat to 
display the X.400 processes that are enabled. 

2. Ifthe process status of any component displayed is "not running!" 
then issue the command x4start. 

3. Use the Managing X.400—Administrator's Guide if problems persist. 
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Running Verification Tests 

The verification strategy described here follows a bottom up approach. It 
first checkstheability of the links to communicate, then theOTS 
Transport Layer, and last the desired service. 

All the verification tests use osidiag. Testing the X.400 services may 
alternatively be performed through x4 admin or the X.400 tools described 
in Managing X.400—Administrator's Guide 

osidiag may be invoked directly from the command line, or through 
osiadmin by selecting 'Test Connectivity->" for the appropriate layer. 


NOTE Hewlett-Packard strongly recommends that you run these verification 

tests even if the problem you are troubleshooting is seen through a 
user-written application. If the verification tests fail, then there is a 
general network problem that you should correct. If these tests pass, 
then the problem is related to your program's behavior. For a description 
on how to further analyze program-specific problems, see "Collecting 
Troubleshooting Data" on page 61. 


Link Verification 

For X.25 

1. For x.25, run the "Loopback..." test under osidiag's "X.25 Test 
Cases." 

2. If you have multi pie X.25 cards, run this test under osiadmin, so 
that osidiag will use the correct default values. 

3. If OTS is not configured to use subaddressing, you will not be able to 
run this test when OTS is running. The error you see is "Address 
already in use."Try running the "Connect..." test instead, making 
sure the Protocol ID field is blank and not "dx25." 

4. If you encounter errors, see "I nterpreting X.25 Errors" on page 42. 

For LAN 

1. For LAN, run the'Test Frames..." test under osidiag's "LAN Test 
Cases." 
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2. If you have multiple LAN cards, run this test under osiadmin, so 
that osidiag will use the correct default values 

3. If you encounter errors, see "I nterpreting LAN Errors" on page 37. 

OTS T ransport Verification 

To verify OTS Transport, do the following: 

1. Go to'Transport Tests-" under osidiag and select the "Loopback..." 
test. 

2. Overwrite the N etwork Address if you want to test a subnetwork 
other than the default. By default, osidiag will run over the first 
LAN subnet configured. If no LAN is configured, then it will run over 
the first WAN subnet configured. 

3. If you encounter errors, see "I nterpreting Transport Errors" on page 
33. 

Run this test for each subnetwork you have configured. The subnetwork 
used is determined indirectly by the network address you specify in step 
2 . 

The other network address values can be found on your Local 
Configuration Worksheets. Alternatively, you can find the other local 
addresses by doi ng the fol I owi ng: 

1. Select the "Status..." test from the'Transport Test Cases" menu. 

2. Look for fields labeled snet_iocai_net_address. These are the 
local network addresses you have configured for your subnetworks. 

Service Verification 

The verification steps for the X.400 and FTAM products are given in 
more detail in the respective "I nstalling and Configuring" manuals. The 
general steps for service verification are outlined below. 

1. From osidiag, select the service to test. Or from osiadmin, select 
'Test Connectivity..." in the menu for the service to test. 

2. Select the "Loopback" test from the menu. For FTAM, use "Connect" 
instead of loopback. 
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3. Use the default configured values that osidiag presents. For more 
information about a parameter, press the "Help" key when in the field 
in question. 

4. If you encounter errors, see "I nterpreting Errors" for the specific layer 
in Chapter 1, "InteroperabilityTesting,"on page 11. 
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Collecting Troubleshooting Data 

If the information already given was not sufficient to isolate and correct 
the problem, usethetracing and logging facilities to gather more 
information. 

The method you use to gather tracing and logging information will 
depend on the error that is produced. Table 2-2 lists the possible 
methods. 


Table 2-2 Troubleshooting Methods 


Type of 
Error 

Troubleshooting Method 

osidiag 

If the problem is reported during a run of osidiag, then usethetracing 
and logging utilities provided by osidiag. This procedure is described in 
the section 'Tracing and Logging through /opt/ots/bin/osidiag" on 
page 62. 

X.400 

If the problem occurs through an X.400 application, then follow the tracing 
procedures described in the Managing X.400—Administrator's Guide 

User 

Application 

If the problem occurs through a user-written application, then there are two 
facilities that can give you further information. This procedure is described 
in the section 'Tracing and Logging User Applications" on page 63. 
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Tracing and Logging through 

/opt/ots/bin/osidiag 

osidiag (Icxiated in the /opt/ots/bin directory) provides the ability to 
automatically capture netti trace and log information and append it to 
the output for a test operation, osidiag also allows you to copy the 
results displayed to the screen to a result file. The following steps 
describe how to enable both facilities through osidiag. 

1. I nvoke osidiag either directly or through osiadmin and go to the 
Utilities menu. 

2. Select "Open Result File" and enter a file to save the results of the 
test operation (for example, /tmp/ftam.res). Thefilespecified will 
be overwritten if it already exists. 

3. Select'Tracing and Logging." 

4. Enable logging for OTS, by placing a 'Y" after its name in the pop-up 
window. Enable tracing for the layer being tested and the layer below. 
So, for FTAM you would enable FTAM and ACSE/Presentation. For 
Transport, you would enable Transport and Network. Usethe "Flelp" 
facility for more information about a particular flag. Press Done on 
the Trace and Log screen after setting the appropriate fields to 'Y." 

5. Use the default values presented for the log and trace levels by 
pressing Done on these screens, and then exit the Utilities menu. 

6. Now rerun the test you are gathering information for. The results of 
the logging and tracing will be displayed on your screen as well as 
copied tothefileyou specified in step 2. 

To analyze the errors logged, see "Common Logged Errors" on page 67. 

The trace information produced may be useful to your FIP support 
representative. I nterpreting traces requires a good understanding of the 
various OSI protocol internals. Some information on trace interpretation 
is given at the end of the "Session," "OTS," "X.25," and "LAN " sections of 
Chapter 1 "I nteroperabi I ity Testing". 
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Table 2-3 


Tracing and Logging User Applications 

Two facilities exist to provide more data about the behavior and errors 
encountered by your application, API tracing and netti. 

API Tracing This facility allows you to trace the callsyour 

application makes tothe Application Programmatic 
I nterface. The mechanism to perform API tracing is 
descri bed i n the programmer's guide for the service you 
are using. 

netti The netti command allows you to enable logging and 

tracing in theOTS stack as well as for the FTAM 
service. The syntax of the netti and netfmt 
commands is given in thenetti(lM) and netfmt(lM) 
man pages. 

Hewlett-Packard recommends that you enablewarning and error logging 
for stack components at and below the service you are using. Table 2-3 
shows the entities on which you should enable logging for gathering 
information. 


Logging and Tracing Entities 


Service/Layer 

Entities to Log 

X.400* 

X.400 Logging facilities 
-fOTS entities 
-FLink entity 

FTAM 

FTAM_VFS FTAM_USER 

FTAM_INIT FTAM_RESP 

-fULA entities 
-fOTS entities 
-FLink entity 

APRI 

ACSE_PRES 

-FOTS entities 
-FLink entity 

OTS 

SESSION TRANSPORT NETWORK OTS 

LAN 802.3 

NS_LS_DRIVER 

X.25 

sx 25 L2, SX25L3 (Level 2 and 3 link tracing) 
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Service/Layer 

Entities to Log 

FDDI 

FDDI 


* The tracing and logging of X.400-specific components can be done 
through x4admin, and is described in the Managing 
X.400—Administrator's Guide Tracing and logging of OTS and the link 
is still performed through netti for X.400. 

Tracing is only recommended if you have a good understanding of the 
protocol internals. When used, it is useful to trace at the layer your 
application uses and one level below. 

For instance, totracean FTAM application, you might enable tracing for 
theFTAM entities and ACSE/Presentation. To trace an XTI application, 
you might enable Transport and Network tracing. The kind of tracing 
will usually be PDU I n, PDU Out, Pleader I n, and Pleader Out. 

To analyze the errors logged, see "Common Logged Errors" on page 67. 
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Common Configuration Mistakes 

The following list describes some common configuration errors that may 

result in failure during verification. The errors are grouped by the 

configuration filethat contains them. 

Seethe"OTS and Related Parameters" chapter in theOSI Transport 

Services manual for detailed information about all the parameters. 

ots_dests Common Mistakes 

• Mistyped dest_net_address or the dest_phys_address, will 
cause a fail in your attempt to connect. 

• Destination entries must be made in order for loopback to work over 
both CONS and CLNS/X.25. Be sure to include any X.25 subaddress 
when specifying the physical address. 

• Destination entries must be made in order for loopback to work over 
CL NS/ LAN when CLNP Subset 0 is used. I n other cases, destination 
entries for LAN should be avoided. 

• Specifying the incorrect outgoing subnetwork for a destination, will 
cause a fail to connect. 

• When specifying reverse charging for X.25, the remote must be 
configured to accept it. Otherwise, it will reject your connection. 

ots_subnets Common Mistakes 

• M istyping your local address will cause the remote systems to be 
unsuccessful in connecting with you. 

• I ncorrect CLNP subset for LAN. This can prevent interoperability 
with other systems on the LAN. Seethe parameter 

snet_clnp_subset. 

• LAN-based networks with a large number of nodes (over 200), should 
have the parameter snet_max_es_entries increased. Not doing so 
can result in failure to establish connections with other systems. 
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• I ncorrect interface name. Specifying an interface name that is not 
configured will result in warnings, but OTS will still start. If 
otsstat indicates any links are "NOT RUNNING,"verify these 
names. 

ots_parms Common Mistakes 

• If dose to the limit of connections available (448 over LAN, 4096 over 
X.25) through OTS, the ses_reuse_tp_con flag may hold open 
connections you need to recycle. 

• If using CONS/X.25, ensure that the Transport class OTS requests is 
acceptable to the remote. Thetpcons_pref_mux_ciass parameter 
determines whether you use class 2 or 4. The parameter 

tpcons_tpO_oniy forces class 0. 

• Some vendors do not accept the OSI Transport protocol ID carried on 
X.25 connection requests. This can be disabled with 

tpcons_null_pid. 

iocai_app Common Mistakes 

• Setting the maximum invocations, or inbound associations too low 
can result in your failing to receive or create connections with remote 
FTAM applications. 

• If you manually edit these files rather than using osiadmin, you 
should besurethat all FTAM application titles match the 

ftam_ddn_iookup_path parameter. 


remote_app Common Mistakes 

• Mistyping a remoteapplication titleor aliasfor FTAM will result in 
your connection failing. 

• Mistypinga remote presentation address for FTAM will result in 
your connection failing. 
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Common Logged Errors 

The fol lowi ng I ist descri bes some of the more common errors logged by 
OTS that you can encounter. These errors are sorted by the subsystem 
name and the message ID as it appears i n the log. 


Table 2-4 Subsystem OTS 


Error 

Description 

[9600] 

High Access 
Method ERROR 

1 ndicates an error in the streams interface between user programs 
and the OTS stack in the kernel. One common problem is attempting 
a bind operation to an invalid network address or SAP. Verify the 
local address used on your test and try again. 

[9800] 
x25 ERROR 

1 ndicates that the X.25 card has not been started or has gone down. 
Useotsstat and x25stat (or their equivalents under osidiag) to 
view the status of X.25. Restart X.25 if necessary under osiadmin. 


Table 2-5 Subsystem ACSEPRES 


Error 

Description 

[6010] 

P_DCNX_KO 

1 ndicates that the presentation layer is releasing the connection 
after some error was encountered. Examinethe log or user 
application for other errors. 

[6011] 

PST_LOG 

Indicates a problem found by the presentation layer in the OTS 
stack. This may indicate a protocol error, or an ASN.l encoding issue. 
Examinethe packets sent in the trace output. 


Table 2-6 Subsystem SESSION 


Error 

Description 

[5008] 

S_REJECT 

1 ndicates that a session connection was not successfully established. 

If the log does not show a t_reject error, this indicates that the 
problem was at the session layer. If a t_reject error is logged, then 
the s_REjECT is just a propagation of a Transport (or lower) layer 
problem. 


Chapter 2 


67 










Problem Solving 

Common Logged Errors 


Error 

Description 

[5010] 

S_DCNX_KO 

This error is logged after the Session layer has successfully 
established a connection, but is releasing the connection in some 
error state. Examine the log or user application for other errors. 


Table 2-7 Subsystem TRANSPORT 


Error 

Description 

[4103] 

Protocol Error 

1 ndicates a protocol error was detected at this layer. You should 
verify that both sides are using correct combinations of Class, 
Alternate Class, Flow Control and Expedited Data. If problem 
persists, ensure that you have both Transport and Network layer 
traces of the dialog, and contact your H P support representative. 

[4108] 

T_REJECT 

1 ndicates that the Transport connection was not successfully 
established. Examine the log for other errors (such as routing 
problems, or network layer problems). If no other logged errors 
appear, the problem may be that no process is listening at the 
address you specified. Verify the remote address given as well as 
what addresses are available at the remote. 

[4113] 

Routing 

1 ndicates that CL NS was unabletodeterminethe NSAP/ MAC 
address translation for the destination Network Address given. 
Possible problems are: mistyped address, remote is not up, remote 
does not support ES/IS, the remote's destination configuration 
(ots_dests) is incorrect. 

[4115] 

Processing 

Error 

This error usually appears in conjunction with a protocol error. It 
may give more information about what was not liked with the PDU. 


NOTE Transport errors will have message I Ds that begin with either 4ixx or 

4 0XX, depending on whether you are running over CL NS or CONS 
respectively. The statements shown below apply as well to the 4 0 xx 
errors. 
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Table 2-8 Subsystem NETWORK 


Error 

Description 

[3003] 

N_REJECT 

1 ndicates the X.25 connection could not be established with the 
remote. Possible problems are that the NSAP/X.121 address 
mapping for this remote is incorrect. Facility negotiation failed with 
X.25 (for example, Reverse Charging, X.25 '80/'84). The remote stack 
or card may not be enabled. The remote system may not be able to 
accept anymore X.25 connections. 

[300 5] 

N_ DCNX_KO 

This error is logged after the Network layer has successfully 
established a connection, but is releasing the connection in some 
error state. Examine the reason code for moredetails. 

[3014] 

N_ERROR 

This may provide more detailed information for why the network 
connection was rejected. Errors regarding route resolution mean that 
your destination address configuration is in error. 
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Submitting Problem Information to HP 

The following items will be very useful in having HP Support diagnose 
problems with your OSI products. 

• Result Files - The output created for all your runs of osidiag. 
Examples of the recommended file names are /tmp/ftam. res and 

/tmp/tran.res. 

• OTS Configuration Files-Thecontentsofthe following files in 

/etc/opt/ots/conf: 


local_app 

For FTAM problems only. 

ots_dests 

For nodes running over X.25 or NULL internet. 

ots_parms 

1 n all cases. 

ots_routes 

1 n all cases. 

ots_subnets 

1 n all cases. 

remote_app 

For FTAM only. 


• X.400 Configuration Report. If you are using X.400 and experience 
problems, type the following: 

/opt/x400/bin/x4dump 

A file called /tmp/x4dump. sh is created which can be e-mailed or 
put on tape. 

• X.25 Configuration Report. If you are using X.25 and experience 
problems, type the following: 

/opt/x25/bin/x25stat -c /tmp/x25.cnf 

Print the resulting file. 

• LAN Configuration Report. If you are using LAN (802.3 or FDDI) and 
experience problems, type the foil owing: 

/usr/sbin/lanscan /tmp/lan.cnf 

Print the resulting file. 
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The software tcx3ls you'll use to configure, maintain, and troubleshoot 
your HP OSI products. 
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OSIADMIN 

The os iodmin (OSI Administrstion) proQrem Qives you eccesstothe 
various configuration, administration, and diagnostic tools you need to 
set up and maintain your HP OSI products, osiadmin acts as an 
umbrella for these tools, providing you with a single, easy way to 
configure, start, stop, and test each product. 

Table 3-1 shows the HP OSI products, administration functions, and 
software tools called by osiadmin. 

osiadmin Functions 


Product 

Function 

Tool 

LAN 

configure 

SAM (SystemAdministration Manager) 


start 

ifconfig 


stop 

ifconfig 


test 

osidiag 

X.25 

configure 

SAM 


start 

x25init 


stop 

x25stop 


view 

x25stat 


test 

osidiag 

OTS 

configure 

osiconf 


start 

otsstart 


view 

osiadmin 


test 

osidiag 


update 

otsupdate 
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OSIADMIN 


RFC 1006 

configure 

osiconf 


start 

otsstart 


view 

osiadmin 


test 

osidiag 

FTAM 

configure 

osiconf 


start 

ftam_resp 


stop 

ftam_resp 


view 

osiadmin 


test 

osidiag 

X.400 

configure 

xiadmin 


start 

xistart 


stop 

x4stop 


view 

x4configprint 


test 

osidiag 


administer 

x4admin 
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Managing Your Configuration 

Using osiconf 

The osiconf program is an interactive configuration tool you can use to 
do the following: 

• Verify that your configuration information has been entered with the 
proper syntax and range, and that it is consistent between OTS and 
FTAM. 

• Modify the OTS and FTAM configuration files. 

osiconf is most commonly used through osiadmin, but it may be 
started alone, osiconf has two "modes:" 

update/dynamic Only dynamic parameters can be modified. Changes 
take effect when you run otsupdate. When dynamic 
changes take effect, they are applied to the running 
OTS or FTAM. 

restart Can modify all parameters in this mode. Changes take 

effect when otsstart is run (if this istheinitial 
configuration), or when you reboot (if you've changed 
an existing configuration). 

For more information, refer to the online FIP-UX man page for osiconf. 

Using osiconfchk 

The os iconfchk program is a configuration verification tool that allows 
you to verify the correctness of configuration files prior to actually 
starting the stack. Checks are performed to ensure that all required 
information is present, that parameters are of the proper syntax and 
range, and that information is consistent across configuration files. 


NOTE For X.400, os iconfchk checks Only those parameters that are also 

configured in OTS. The osiconfchk program does not verify the 
correctness of the X.400 configuration. 
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The directory where the configuration files may be found is specified by 
setting the environment variableosi_coNFiG. If osi_config is not set, 
/etc/opt/ots/conf is searched as the default location. 

Running osiconfchk 

Follow these steps to run the osiconfchk program: 

1. Login as root. 

2. Type osiconfchk. For details on the options and variables, refer to 
the FI P-UX online man pages for osiconfchk. 

3. I f there are no parameter problems, the root prompt re-appears. 

Troubleshooting Using osiconfchk 

If osiconfchk finds problems with the configuration parameters, it 
displays the file the problem was in, the line of the file, and the actual 
parameter at fault. The example below shows a sample output of 

osiconfchk errors. 

/etc/opt/ots/conf/local_app 
Line 26: 

->ae_local_paddr 7874693.0001.0001 # p-, s-, and t_selector 
An even number of hexadecimal digits is required. (CHK023) 

First line Configuration file name from X.25, OTS, FTAM, or 

X400. 

Line number This is the line number from the file. 

Next line The actual parameter name and value of the 

parameter. 

Last line A statement of what osiconfchk found wrong with 

the parameter. 

Compare this display with the parameter value on the appropriate 
worksheet to be sure it was entered correctly. 

Read the problem descriptions and takethe recommended actions to 
correct the configuration problems. 
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Table 3-2 


OSI Diagnostics 

Theosidiag (OSI Diagnostic) program allows you to verify that the OSI 
services provided bytheHP network node are operational. You'll use 
osidiag throughout the remote interoperability procedures. It can also 
be used as a layer troubleshooting aid in determining the functionality of 
the suspect component. You can start osidiag from within osiadmin or 
directly from the HP-UX system prompt. 

Table 3-2 shows the components of the OSI stack and the tests provided 

by os idiag. 


Tests Provided by osidiag 


Component 

Test 

FTAM 

1 nitiator 

Tests the communication between HP's FTAM 

1 nitiator and the specified remote responder. 

X.400 

Four tests are avail able for X.400: 

• The RTS connection tests provide verification of 
HP's ability to establish or receive connections 
at the RTS layer. 

• The User Agent connection test verifies H P's 
ability to send an X.400 message and receive a 
delivery confirmation from the remote node. 1 n 
order to provide more feedback to the user, this 
test will track message activity as the message 
transfers from one X.400 process to another. 

• The RTS loopback test does a local loopback test 
to verify that the RTS can communicate with 

OTS. 

ACSE/ 

Presentation 

Allows you tocreateor receive ACSE/Presentation 
connections and send data. 

ROSE 

Allows you to create or receive connections over 
ACSE/ Presentation /ROSE and issue and receive 
operation invocations. 
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NOTE 


Component 

Test 

Session 

Provides verification of H P's ability to establish or 
receive connections at the session layer. Data, 
expedited data, and some of the activity 
management primitives may also be sent on this 
connection. 

T ransport 

Provides verification of H P's ability to establish or 
receive connections at the transport layer. Data, 
and expedited data may also be sent on this 
connection. Please read that follows this table. 

X.25 

Allows an X.25 connection to be established and 
brought down verifying layer 3 connectivity with 
the remote node. Card status and statistical 
information can also be reported. 

LAN (802.3/ 
FDDI) 

Uses the 802.3 Test Frames to determine if there is 
layer 2 connectivity. Card status may also be 
reported. 


An entity must be running on the remote node, capable of receiving (or 
initiating) a session or transport level connection. For the HP node, 
osidiag provides the capabi Iity to both establish and receive the 
connection. H owever, some vendors may not have exposed access to this 
layer or the functionality provided by osidiag. I n that case, thetest 
desired may have to be run manually (without osidiag). 

With osidiag, you can automatically start tracing and logging while 
running diagnostic tests at a specified layer of the stack. By designating 
a "Result File," you can store a duplicate of the information displayed 
while the test case is running. This file can be useful in relaying problem 
information if consulting help is requested. For more information on 
osidiag, see the online manpage. 
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Starting and Stopping OSI 

Occasionally, while configuring, verifying, or troubleshooting any of the 
OSI products, you'll need to start or stop the OSI products. Use the 
commands descri bed here. 

osistart Command 

Execute the osistart command from the system prompt. Useittostart 
services, such as FTAM and X.400 along with the OTS component and 
whatever links are being used. Issue the osistart command with no 
options. 

You can start the services separately by using the -s option. This also 
starts the OTS and link components (if necessary). For example: 

osistart -s x400 

For more details on the osistart command and its options, refer tothe 
FI P-U X onl i ne man pages. 


NOTE If you make OTS configuration changes via osiadmin to start OTS 

automatically, OTS/9000 is automatically started when the system is 
booted. Thus, OTS is usually up and will rarely (if ever) be started by 
osistart. See "OSI ADM IN" on page 72 for the list of tools that 
osistart uses to Start the OSI stack. If you don't make the 
configuration changes using osiadmin, you must use otsstart 
manually to start OTS. 
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Stopping OSI 

To stop the OSI stack, you must shutdown your system. After initial 
installation of OTS/9000, the OSI stack will start automatically after 
rebooting. If you do not want it to start automatically, edit the 
/etc/rc. conf ig. d/ots file and change the value of otsstart to "off." 

osistat Command 

Super-users can use the osistat command to get the status of various 
aspects of OSI service products, for example: 

• active service providers 

• aborts sent 

• aborts received 

• connections established 

Executed fromthesystem prompt, the osistat command with no option 
prints global service provider process (SPP) statistics for FTAM. With 
the -m option, osistat prints memory buffer statistics without SPP 
statistics. 
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Starting OTS: otsstart 

This section tells you how to start OTS/9000 directly from the HP-UX 
shell command line. See the section 'ToStart OTS/9000," in chapter 5 of 
the OSI Transport Services manual, for how to start OTS/9000 from 

osiadmin. 

otsstart starts the protocol subsystems, andtheCONS and CLNS 
parts of the network layer. This command requires super-user capability. 

Before executing otsstart, make sure the following are true: 

• The OTS/9000 subsystem is configured. 

• The X.25 software is configured and started, if used. 

• The LAN link is running, if used. 

• No X.25 layer 3 applications (that is, x25server, x2 9server) are 
running, if null subaddressing is used. 

Syntax 

otsstart 

path: /opt/ots/bin 

OTS/9000 can only be started once per system boot-up. Subsequent 
invocations of otsstart have no effect. To check whether OTS/9000 is 
running, seeotsstat later in this chapter. 

Example 

The following example shows otsstart executed when OTS detects a 
problem with the LAN card and the X.25 cards: 

startup log: 

OTS: running 

lanO: NOT RUNNING 

telenet: NOT RUNNING 
telenetl:DOWN 

1. Check to make sure that lanO LAN and the telenet and telenetl 
X.25 links are running and properly configured. X.25 may be: 

NOT 

RUNNING not configured or not started 
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DOWN not configured, but level 2 is down 

2. Next, make sure that OTS is properly configured to use these links. 

3. Finally, make sure that no other applications are conflicting with 
OTS's use of these links. 

Recovering from otsstart Failure 

In most cases, when otsstart fails, you will need to change the 
configuration before trying to start OTS/9000 again. Use the error 
messages from otsstart and osiconfchk as a guide for making 
changes. 

If an error is reported before "Starting OTS", fix the configuration and 
try again. If the error occurs after "startup log:", you'll have to fix the 
error and reboot. 
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Checking OTS Status: otsstat 

If connectivity problems occur, one of the first actions to take is to find 
out whether OTS/9000 and the network services are running. The 
otsstat command tells you if OTS/9000 is running and whether the 
OTS/9000 subsystem can successfully communicate with the X.25 and 
LAN software. The X.25 status is reported in terms of each card's 
programmatic access name. The LAN status is reported in terms of the 
LAN interface name. 

LAN status may be "running" or "NOT RUNNING." 

X.25 status may be: 

running 

NOT RUNNING not Configured or not started 
DOWN level 2 is not running 

If the OTS/9000 subsystem is running, but X.25 or LAN is DOWN or 
NOT RUNNING, do the foil owing: 

1. Verify the X.25 network service is operational. If not, restart X.25. 

2. Verify the LAN card is accessible. For example, perform a LAN 
loopback test. 

3. If the OTS status still reports the X.25 or LAN as down, reboot. 

4. Run osidiagtoverifyOTS/9000can communicate over the X.25 link 
and/or over the LAN. 

It is possible for OTS/9000 to be running after a network service (for 
example, X.25) has been stopped. The result is that applications (for 
example, X.400) will not be able to communicate over OTS/9000, if that 
particular network service is required. 

Syntax 

otsstat 

path: /opt/ots/bin 
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Example 1 

The following example shows the output of otsstat when OTS/9000 is 
running and can properly communicate with X.25 and with LAN. The 
programmatic access name for the X.25 card is telenet. The interface 
name for the LAN isianO. 

/opt/ots/bin/otsstat 

OTS: running 

lanO: running 

telenet: running 

NOTE The otsstat command does not include the status of the X.25 and LAN 

network services. To check their status, usethex25stat and lanscan 
commands. 


Example 2 

The following example shows the output of otsstat when theOTS/9000 
subsystem is not running: 

/opt/ots/bin/otsstat 
OTS: NOT RUNNING 

Example 3 

The following example shows the output of otsstat when OTS/9000 is 
running, cannot properly communicate with the X.25 link software, but 
can communicate with LAN. 

/opt/ots/bin/otsstat 

OTS: running 

lanO: running 

telenet: DOWN 
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Updating OTS: otsupdate 

Chapter 5 of the OSI Transport Services manual describes many OTS 
configuration parameters as being "dynamic."This means that you may 
change the values of these parameters and have them take effect while 
OTS/9000 is up and running. Non-dynamic parameters take effect only 
after the system has been rebooted. 

After changing dynamic parameters with osiadmin or any ASCII editor, 
use the otsupdate command to cause the changes to take effect. I f 
you've changed a non-dynamic parameter, the update process will not 
allow any updates to occur. The update process is very sensitive to the 
changing of non-dynamic parameters. For example, deleting and 
re-adding a local subnetwork (even with exactly the same values) could 
cause the update process to fai I. 


NOTE If changing parameters with osiadmin, you can restrict your updates to 

dynamic parameters only by setting the update mode to dynamic (D). 


In general, parameters dealing with protocol layer operation (for 
example, timers), and parameters dealing with remote addressing (for 
example, destinations and routes) can be updated using otsupdate. 

For additional information, seethe man page for otsupdate. 
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Dynamic Routing Commands 

Dynamic routing commands provide an alternative to using otsupdate. 
Use of these commands may be more efficient than using otsupdate 
when the information is small and restricted to routing information. 

OTS routing information is contained in the Routing I nformation Base 
(RIB). The information contained in this database can be changed using 
a set of user commands. 

U se these commands to: 

• View the current Rl B entries. 

• Dynamically update the stack's RIB. 

• Make changes to the local configuration file. 

You can change or view routing information for: 

• E nd Systems 

• I ntermedi ate Systems 

• Routes 

• NSAPs 

End System Commands 

End systems are nodes directly reachable from the local node. 

otsaddes 

ADD: Adds a single end system entry to the specified subnet. Now also 
supports per-destination protocol identifiers (PI Ds). 

otsaddes es nsap subnet name es phys addr [options] 

[options] = -ccug, -f|F, -r|R, -s|S, -t|T, -w, -x|X 

otsdeles 

DELETE: Deletes the specified end system entry. 

otsdeles es_nsap subnet_name [-w] 
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otsshowes 

VIEW: Displays all end system entries for the specified subnetwork. 

otsshowes subndt_namG 

I ntermediate System Commands 

I ntermediate systems are nodes di rectiy reachable from the local node 
that function as inter-network or intra-network routers. 

otsaddis 

ADD: Adds a single intermediate system entry to the specified 
subnetwork. 

otsaddis is nsap subnet name is phys addr [options] 

[options] = -C, -fiF, -r|R, -Sis, -t|T, -w, -x 1X 

otsdelis 

DELETE: Deletes the specified intermediate system entry. 

otsdelis is_nsap subnet_name [-w] 

otsshowis 

VIEW: Displays all intermediate system entries for the specified 
subnetwork. 

otsshowis subndt namG 
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E S/I S Parameters 


Table 3-3 ES/IS Command Parameters 


Argument 

ots_dests 

Parameter 

Description 

es_nsap 

dest_net_address 

Specifies the end system's N SAP 

is_nsap 

dest_net_address 

Specifies the i ntermedi ate system's N SAP 

subnet_name 

dest_out_subnet 

The symbolic name for the outgoing 
subnetwork to which this end system is 
attached. This name must have been 
previously configured before OTS startup. 

es_phys_addr 

dest_phys_address 

The physical point of attachment to the 
subnetwork. This will be a X.121 address for 
X.25 or a MAC address for 802.3/FDDI 
subnets. 

is_phys_addr 

dest_phys_address 

The physical point of attachment to the 
subnetwork. This will be a X.121 address for 
X.25 or a MAC address for 802.3/FDDI 
subnets. 
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Table 3-4 E S/I S Command Options 


Option 

Description 

-r 

Reverse Charge Request off. Specifying this option prohibits outgoing calls 
from requesting reverse charging. This is the default. 

-R 

Reverse Charge Request on. Specifying this option makes outgoing calls 
request reverse charging. 

-xN 

X.25 level of service. n=[0-3]. 

OisX.25ISO 8878 

1 is X.25/1980 

2 is X.25/1984 

3 is X.25/1988 

Specifying this option turns off support for the service specified by n. The 
default is to have all possible levels of service supported. Only those levels 
supported by the subnetwork are valid. See the file ots_subnets for related 
parameters. 

-xN 

X.25 level of service. N=[0-3]. 

0 is X.25 ISO 8878 

1 is X.25/1980 

2 is X.25/1984 

3 is X.25/1988 

Specifying this option turns on support for the service specified by N. The 
default is to have all possible levels of service supported. Only those levels 
supported by the subnetwork arevalid. See the file ots_subnets for related 
parameters. 

-f 

Flow control off. Specifying this option disallows flow control parameters 
(packet size/window size) to be negotiated. This is the default. 

-F 

Flow control on. Specifying this option allows flow control parameters 
(packet size/window size) to be negotiated. 
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Option 

Description 

-p pid 

Specifying this option causes a destination protocol identifier (PI D) to be 
configured for this destination. This value is specified as 2 to 16 hexadecimal 
digits (must be an even number of digits) or the word "NULL" (without the 
quotes). If you use a hexadecimal value, this value is used as the destination 

PI D on connection requests to the end system. If the PID is configured 
"NULL", the NULL PI D is used. This option is only valid for end systems 
connected over CONS/X.25. If no option is specified, OTS chooses the 
destination PID. Refer tothe dest_pid parameter. 

-s 

Fast Select off. Specifying this options disallows user data to be sent with 
call set-up and clear packets. This is the default. 

-s 

Fast Select off. Specifying this options allows user data to be sent with call 
set-up and clear packets. 

-t 

Throughput Class Negotiation off. Specifying this option disallows 
throughput class to be negotiated. This is the default. 

-T 

Throughput Class Negotiation on. Specifying this option allows throughput 
class to be negotiated. 

-w 

Write this action (add or delete) tothe ots_dests configuration file. Default 
is no write. 

-ccug 

Closed User Group, cug specifies the closed user group to which this end 
system belongs, cug is four decimal digits long, padded on the left with zeros. 


NOTE The X.25 parameters (for example, flow control, fast select, etc.) can only 

take effect if the X.25 card configuration allow the parameters to be 
negotiated. 


Route Commands 

Routes specify paths to nodes that can be reached via an intermediate 
system. A route may specify such a path for a single system by using a 
full NSAP, or groups of NSAPs by using their Network ID. (A Network 
ID is an NSAP prefix common to a group of destination NSAPs that can 
all be reached through the same intermediate system.) 
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otsaddroute 

ADD: Adds a single route entry for the specified subnetwork. 

otsaddroute net_id subnet_name is_nsap [-mMask] [-w] 

otsdelroute 

DELETE: Deletes the specified route entry. 

otsdelroute net_id subnet_name [-mMask] [-w] 

otsshowroute 

VIEW: Displays all route entries for the specified subnetwork. 

otsshowroute subnGt name 


Route Command Parameters 

Table 3-5 Dynamic Route Commands 


Argument 

ots_routes 

Parameter 

Description 

net_id 

route_id 

Specifies the end systems N SAP or network 1D. 

If this value is the full length end-system 

NSAP, then this route entry will send 
information for this particular destination 
through the specified intermediate system 
(is_nsap). If this value is a prefix of an NSAP, 
then it is used to specify a group of systems, all 
having this common NSAP prefix. 

subnet_name 

route_out_subnet 

The symbolic name for the outgoing 
subnetwork to which the intermediate system 
is attached. This name must have been 
previously configured before OTS startup. 

is_nsap 

route_primary 

Specifies the intermediate system NSAP. 

1 nformation destined for the end system will be 
sent through this system. 
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Route Command Options 


Table 3-6 Route Command Options 


Argument 

Description 

-w 

Write this action (add or delete) to the ots_routes configuration file 
making the change permanent. The default is no write. 

-mM ask 

Network ID mask. Mask is a bit mask, specified in hex digits. It specifies 
how may bits in the network ID are significant when resolving addresses. 

For instance, with Mask of FFF8, the first 15 bits will be used when 
matching the route entry to the destination NSAP. If no-m option is 
specified, a mask of N F'swill be used, where N is the number of hex digits 
i n the N SAP/network 1D. 


NSAP Commands 

Network Service Access Point (NSAP) addresses are used to identify real 
systems unambiguously on a network. Dynamic N SAPs are used for high 
availability clusters running the MC/ServiceGuard product, which 
automatical ly shares N SAPs when a node or its network 
communications fail. Usethefollowing commands to add, delete, and 
show dynamic NSAPs for local CONS/CLNS subnetworks. Seethe 
manpages for these commands for more information. 

otsaddnsap 

ADD: Adds a local N SAP to OTS configuration for a specified network 
service. 

otsaddnsap service nsapvalue [silent] 

The silent option means the added NSAP is never broadcast in the 
ESH packet. 

otsdelnsap 

DELETE: Deletes a local NSAP from OTS configuration. The 
default/main NSAP configured via osiadmin cannot be deleted with 

otsdelnsap. 

otsdelnsap (nsapvalue) 
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otsshownsaps 

VIEW: Shows local NSAPs configured for a specified network service. 

otsshownsaps 
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